[レポート]Application modernization using Amazon EKS Blueprints for AWS CDK #reinvent

はじめに

CX事業本部の佐藤智樹です。

本記事はAWS CDK Advent Calendarの6日目の記事です。re:InventのセッションでCDK+EKSに関するワークショップが開催されていたので紹介します。

全体的にCDKのEKS Blueprintの紹介とBlueprintの機能やコンセプトについて説明がありました。EKS Blueprintとはクラウドインフラの複雑な部分を開発者から抽象化し、簡単にワークロードをデプロイできるようにするためのオープンソースの開発フレームワークです。コンテナ実行サービス、CI/CDパイプライン、ログ/メトリクスの取得、セキュリティ強化など、複数のAWSサービスまたはOSSによって構成されています。EKS BlueprintはTerraformとCDKで提供されており、本ワークショップではCDKの方のワークショップでした。

EKS Blueprintについて知りたい場合は以下の記事も参考になるかと思います。本記事ではワークショップ内で以下の記事以上に詳細なコンセプトが紹介されていたので後半で紹介します。

登壇者

• Young Jeong氏 Specialist Partner Solution Architect, AppMod AWS
• Andrew Park氏 Specialist Partner Solution Architect, AppMod AWS

事前説明

私たちのセッションには、もっとたくさんの背景があります。今日のセッションでは、古典的なソフトウェアについて考えてみます。基本的に、私たちが開発者にできるようにしたいことは、機能を提供できることです。

開発チームは、ソリューションを迅速に反復およびテストする俊敏性やアプリ間の通信ポリシーやガードレールなどを必要としています。また開発チームは、UIによるPull Request承認などの非直感的作業やインフラチームからの介入、自動化されてない作業などいくつかの問題を抱えています。

基本的に、私たちがここでやりたいことは、構築可能なさまざまなプラットフォームで分離することです。2つのペルソナに注目してください。まず、Platform Engineerがインフラをプロビジョニングし、Software Engineerがコードをプッシュすることだけに集中できることを計画しています。

今回のワークショップでは以下をゴールとします。クラスタ横断的に標準とベストプラクティスの適応。アプリケーションチーム間の境界を作り。アドオンの依存性の確認。新しい環境を自動的に追加。単一のソースから構成とアップグレードを管理。基本的に、一元管理されたプラットフォームを作り、その上にアプリケーションが重なるようにするのが私たちの目的です。

今日のプラットフォームは、リリースした後に、そのアプリケーションを実際に構築します。これは基本的に、私たちがAmazonの顧客のようなものを構築しています。

Blueprintは今年発表したフレームワークで、アカウントやリージョンをまたいだクラスタの設定やデプロイを可能とします。では、実際にはどうなのでしょうか。以前からクラスタをデプロイするのは難しいことではありませんが、クラスタの設定をすべて行い、さらに多くのチームを抱えている場合、異なるチーム間で従来の環境をどのように提供すればよいのでしょうか。そこで、私たちが解決しようとしている目標の1つは、よりきめ細かいエクスペリエンスを提供し、トップレベルのあらゆることに対応できることです。

私たちは、BlueprintのAdd-onsで再利用可能なレシピについて話をしたい。スライドのようなAdd-onをBlueprintで比較的簡単に組み込むことができます。

Blueprintには、CDKのものとTerraformのものがあります。今回のワークショップではCDKのものを紹介します。

Blueprintでは、クラスター管理、アドオン管理、チーム管理、アプリケーションデリバリーを実現できます。このツールは、ユーザーとその関連する役割のプロセスを尊重し、アプリ開発に集中できるという考えです。つまり、できるだけシームレスに、顧客のために革新的なものを提供できるようになります。

(佐藤補足：上記の部分はあまり説明されなかったのですが、この画像読むとBlueprintで出来ることが大体わかりそうなので、日本語翻訳記載します）

ワークショップ本編

ワークショップ本編では、以下のリポジトリを使ってのEKS Blueprintについて学び、EKSの構築やCI/CD用パイプラインの追加などを実施しました。

ワークショップ内では、そのままCDKでEKS作成する場合と比べてEKS Blueprintを使う場合、ベストプラクティスに従って、任意の数のアカウントとリージョンに EKS クラスタを展開できることや各クラスターで実行されるアドオンを含むクラスター構成を単一のGitリポジトリから管理できることなどが紹介されていました。

ワークショップを進めると以下のアーキテクチャの構築が大体作成できました。実際はArgoCDによるデプロイまでは作成に含まれていました。

説明内には以下の画像をもとEKS Blueprintのコアコンセプトの説明もありました。

コンセプト	説明
Blueprint	クラスタ、アドオン、およびチームを、全体としてデプロイ可能なまとまったオブジェクトにまとめる
Cluster	ベストプラクティスに従ってEKSクラスタがデプロイ
Resource Provider	クラスタに外部のAWSリソース（ホストされたゾーン、VPCなど）を供給する抽象化されたもの
Add-on	k8sアプリをサポートするための重要な機能を提供する運用ソフトウェア、またはアドオンを設定、デプロイ、更新できるようにする
Teams	k8sのネームスペースにアクセスできるIAM IDの論理的なグループ、またはチームタイプに応じてクラスタ管理アクセス権を持つIAM IDの論理的なグループ
Pipelines Application	クラスタとアドオンをデプロイするための継続的デリバリーパイプライン。EKS Cluster内で実行されるアプリ

自分の解釈としては、アプリケーションのコアな部分以外（ログ、トレーシング、CI/CDなど)は可能な限りPlatform Engineer側の構築に寄せて、Software Engineerはアプリに集中する構成を追求する。そのために共通で必要なリソースやAdd-on、アクセス権限、パイプラインなどはPlatform側に寄せる構成を素早く作るためのEKS Blueprintなのだと理解しました。

またワークショップで内でEKS Blueprintを使って構築する場合のサンプルパターンが置いてあるリポジトリについても紹介がありました。Add-onにSnykやNewRelicなどを仕込む方法なども紹介されており実際構築する際に参考になりそうです。

ワークショップ自体は当日のみの公開だったので詳細はご紹介できないのですが、今後公開される予定はあるそうなので気になれば今後試していただければと思います。1点注意としては、EKS Blueprintの初期構築でデプロイに30分程度はかかったのでデプロイ時間にはご注意ください。

所感

EKSに関しての知識が薄かったのですが、ECSと比べてEKSだとk8sのエコシステムに乗っかって構築できるという話が少しだけ理解できました。ワークショップ自体は、デプロイパイプラインまで構築する実践的なものでかなり面白かったです。re:Inventではセッションごとに100 level(一般的)から400 level(専門的)までレベルがあるのですが、本セッションは400 levelのもので非常に知的好奇心を満たせるものでした。皆さんも来年参加される場合は、400 levelに挑戦しても良いかなと思います。

本記事がEKS Blueprintを理解するための助けになれば幸いです。